'use strict'
const merge = require('webpack-merge')
const prodEnv = require('./prod.env')
console.log(process.env)
module.exports = merge(prodEnv, {
  NODE_ENV: '"development"'
})
/**
 * vuecli2.x构建的项目目录和vuecli3.x/4.x是不同的，毕竟版本在升级，优化也越做越好
 * 我们接下来只讲vuecli2.x是如何配置环境变量的
 * 一般会划分哪些环境呢？
 * 开发环境development，测试环境test，正式环境production
 * 为什么要划分？
 * 开发的时候我们访问接口地址都是访问他们的ip地址
 * 开发完了项目打包到放到测试服务器，你的接口地址要变成测试地址
 * 上线了接口地址又要改成正式地址
 * 总不能每次手动切换把，而且不仅仅是接口地址，还有可能有其他的东西也需要根据不同的环境设置不同的值
 * 如何配置环境变量？
 * 配置环境变量很简单，我们初始化项目的时候，脚手架已经为我们配置好了最基本的环境变量，我们看config文件夹中
 * 截图
 * 已经设置了一个NODE_ENV，然后我们在项目组件中或者js文件中直接通过process.env.NODE_ENV拿到值，然后根据这个值
 * 去做我们想做的事情，当然也不仅仅只有NODE_ENV，你还可以设置任何你想设置的。
 * 这个时候我们有没有想过，为什么在组件中或者js文件中直接通过process.env就能访问呢？
 * 来看看我们一开始执行脚本把
 * 运行项目执行npm run dev,
 * 打包项目执行npm run build
 * 截图
 *
 * 里面的scripts字段是一个对象。它的每一个属性，对应一段脚本。比如，build命令对应的脚本是node build/build.js。
 * npm 脚本的原理非常简单。每当执行npm run，就会自动新建一个 Shell，在这个 Shell 里面执行指定的脚本命令。

 因此，只要是 Shell（Bash）可以运行的命令，就可以写在 npm 脚本里面。
 所以node build/build.js，就是在shell里面用node去执行build文件夹中的build.js文件，
 我们抽取build.js文件中的一段代码
 const webpackConfig = require('./webpack.prod.conf')
 他是不是引入了webpack.prod.config.js文件
 再看webpack.prod.config.js文件中的一块代码
 const env = require('../config/prod.env')
 他是不是引入了config文件夹中prod.env.js文件
 再看下面这段代码
 plugins: [
 // http://vuejs.github.io/vue-loader/en/workflow/production.html
 new webpack.DefinePlugin({
      'process.env': env
    }),
 ]
 他是不是将env也就是prod.env.js导出的模块应用了
 我们看看prod.env.js
 截图
 这个时候肯定好奇new webpack.DefinePlugin这是啥？我在学的时候也好奇
 https://webpack.docschina.org/plugins/define-plugin/
 去截图
 说白了
 new webpack.DefinePlugin({
      'process.env': env,
      a:JSON.stringify('aaa')
    }),
 ]
 我们在组件或者js文件中访问process.env是因为将process.env整体作为全局变量，因为env又是一个对象，所以process.env.NODE_ENV
 我们还可以直接访问a，得到’aaa‘
 但是一般我们只添加个'process.env'，需要的key=value都写在env对象中，也就是在dev.env.js或者prod.env.js文件中


 同理
 npm run dev 其实就是通过webpack-dev-server在本地给我们起了一个服务。也是通过脚本执行build/webpack.dev.conf.js文件
 他里面也写了
 new webpack.DefinePlugin({
      'process.env': require('../config/dev.env')
    }),
 你开发环境要用哪些变量就写在dev.env.js中就行了
 以上只是解释了初始化项目之后最基本的配置

 接下来讲讲打测试包和打正式包
 不管是测试还是正式环境变量都是production，我们只不过为什么区分他定义了test和prod
 看下面
 "build:test": "cross-env NODE_ENV=production env_config=test node build/build.js",
 "build:prod": "cross-env NODE_ENV=production env_config=prod node build/build.js",
 我们可以自己去配置脚本
 然后打测试包，执行npm run build:test，这个时候要一个细节，cross-env是干什么的
 cross-env是用来跨平台设置环境变量的，NODE_ENV=production env_config=test就是我们手动设置的环境变量
 注意：这儿设置的环境变量和DefinePlugin设置的环境变量要区分，他们可不是一样的
 通过cross-env设置的环境变量是在node环境中设置的环境变量。通过process.env去访问，这个process在node中是真实存在的
 process.env可不止有NODE_ENV=production env_config=test，还有很多很多其他的变量
 说白了就是编译时生成的变量，仅编译时可用。
 而DefinePlugin设置的环境变量是运行时的环境变量，项目在运行，代码中随处可访问，
 为什么会搞个cross-env来设置环境变量呢？
 之前我们也说了在webpack.prod.conf.js中直接是引入的prod.env.js
 const env = require('../config/prod.env')
 但我们要区分测试还是正式，所以再新增一个test.env.js的文件，
 这个时候要改造 const env = require('../config/prod.env')
 const env = require('../config/' + process.env.env_config + '.env')
 我们可以通过process.env.env_config去区分引入test还是prod
 注意哈，刚刚也说了执行脚本的时候再node环境创建了env_config变量，node执行build.js文件的时候，就可以在js文件中通过process.env访问
 这个应该能理解（比如写一个在一个js文件中直接console.log(proceess.env)然后再控制台用node执行这个js文件，就明白了）
 npm run build:prod也是同理的
 这个时候是不是就已经区分了不同的环境了
 还没完
 如果我想在xx.env.js文件中我们要设置的环境变量搞个动态的
 比如
 module.exports = {
 BASE_API: `'${request_url}'`
 }
 这个BASE_API的值不能写死，这时候可能会想，不是已经划分不同的环境了吗，已经很灵活了，为什么还要设置动态的环境变量？
 正常是写死就好了？但是我们公司不是？所以我这儿就再写点
 前面不是已经说了在脚本出设置node环境变量吗？打个部分，我们设置成这样
 "build:test": "cross-env NODE_ENV=production env_config=test request_url=https://111.222.com  node build/build.js",
  然后再test.env.js中这样写
 const {request_url = ""} = process.env;
 module.exports = {
    NODE_ENV: '"production"',
    BASE_API: `'${request_url}'`
};
 这样就设置成动态的了
 还有个操作，
 如果在我们本地直接运行npm run build:test，执行下面脚本是没问题的
 "build:test": "cross-env NODE_ENV=production env_config=test request_url=https://111.222.com  node build/build.js"
 但是这段脚本可以被替换，request_url可以改成其他的
 这就是为什么我说环境变量可以设置成动态的原因，更加灵活，总结这个也是因为最近才遇到的，也是思考了许久想清楚的
 * */
